Organizations providing information technology services to customers face a problem of separating their own data from their customer's data. This problem is exacerbated when the customer is a national government and the information technology service provider is a multi-national company. In such a situation, the customer must provide a system of protective markings for its data which the information technology service provider's global infrastructure may not support. Oftentimes, only a portion of an information technology service provider's staff possesses the needed security clearances to process the data a customer requires. As a result, there is a need for the information technology service providers to have some of its employees access the data, while preventing other employees from doing so.
Traditionally, the service provider's environment and the customer's data environment have been completely separated where security concerns exist. In these, so-called “air-gapped” situations, the service provider's staff work in an environment provided by the customer, which environment has been appropriately cleared for the appropriate level of information security. Most of the time, these environments are located on the customer's premises.
While it is abundantly certain that the information technology service provider's staff members must hold the appropriate security clearances to access the information in question, what is not certain or unavoidable is the need for the respective staff members to work at the customer's premises nor is it clear that there must be multiple separated systems for the service provider. In fact, many situations make providing information technology services in such restricted situations both economically and managerially untenable.
One approach to addressing these problems employs a concept called a security domain. Briefly, a security domain provides an aggregation of users, network connections and information technology equipment within which data may be processed subject to discretionary access control. For a security domain, a boundary is defined across which strict control of all data transfer occurs. From a customer's viewpoint, the security domain where the customer both physically and electronically controls the users and the data is generally considered as different from the security domain relating to the information technology service provider. While appropriate handling of data according to marking may be achieved by both electronic and procedural means, handling procedures determine whether a security domain is a “high security domain” or a “low security domain.”
Within a security domain the relative sensitivity of data elements is indicated by a system of markings, which may be explicit or implicit. For example some data may be “not protectively marked”, some may be “restricted”, some may be “confidential”. Appropriate handling of data according to marking is achieved within the domain and at its boundary by a combination of electronic and procedural means. The strength of the means must be appropriate to the volume and sensitivity of the data and the threats faced if the domain is to be regarded as secure by its owner. The threat faced by a domain which communicates with no other domain is significantly less than that faced by a domain which intercommunicates with another. When two domains intercommunicate it is frequently the case that the systems of marking within each domain will be different. It is likely that there may be equivalence between markings at the lowest level of sensitivity, but at ligher levels this is unlikely unless there is some arrangement between the owners of the two domains. When non-equivalence between the marking systems in two domains exists then every marking in one domain which does not exist in the other must by definition prevent export of data so marked across that domain boundary. When one domain may intercommunicate with another at one shared low level of sensitivity marking, but also contains data at a higher level of sensitivity which may not be communicated it is convenient to denote that domain as “high”, and the other domain as “low”.
Thus, a customer having “restricted” and “not protectively marked” data would see his security domain as a high security domain relative to his information technology service provider. This would be due to the information service provider having the ability to support the “not protectively marked” sensitivity of data, but not the “customer restricted” sensitivity data. On the other hand, from the information technology service provider's perspective, it may very well be the case that the customer's security domain would be a low security domain as to the proprietary or otherwise protected information directly and separately pertaining to the information technology service provider.
It is most economical to locate the information technology service provider's staff in the provider's own security domain, which his customers are likely to view as “low” with respect to their own individual domains which they will regard as “high”. However, those providing services in support of high security domain data and programs must comply with the needs of their customers to reduce or eliminate threats to the confidentiality, integrity and availability of their systems and data.
One solution is to completely separate high security domains and low security domains such that only high security domain computers can process high security domain programs and data. Unfortunately, to do so can double or even further increase the number of workstations required in providing the appropriate level service to the high security domains.
Another solution to the problem provides compartmented mode workstations. Unfortunately, such an approach does not permit the use of standard commercial operating systems and applications. As a result, maintenance costs and interoperability limitations plague known approaches using compartmented mode workstations.
Accordingly, there is a need for an economical method and system that provides the information technology service provider and the different customers served the ability to support differing security domain requirements.
A further need exists for providing an information technology service provider the ability to support from his own equipment a variety of customer's security domain requirements when each customer views the information technology service provider as operating in a low security domain.
A further need exists for addressing the problem of a first security domain, which may be considered high security domain relative to a second security domain, needing to avoid having data from the first security domain flow into the second, comparatively lower, security domain.